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Method for routing a service request in a telecommunication system, using 
E.164 numbers and a DNS. 

FIELD OF THE INVENTION 

[0001] The present invention relates to a method and an 
5 apparatus for routing a service request in a 
telecommunication system towards a destination user 

BACKGROUND 

[0002] Users of telecommunication systems use to be 
assigned to one or more identifiers. Such identifiers are 
10 intended to be used by other users for requesting 
communications, and can take various formats according to 
the specific telecommunication technology for which they 
where devised. 

For example, E.164 numbers (ITU recommendation E.164, May 
15 1997) (commonly known as "telephone numbers") are usually 
used as identifiers in legacy telecommunication systems 
such as: PSTN (Public Switched Telephone Network), ISDN 
(Integrated Services Digital Network) , or 2G (second 
generation) mobile systems. E.164 numbers where primarily 
20 defined for allowing routing telephony calls based on its 
numeric structure. So, for example, an E.164 number such as 
"+34 91 555 XXXX" could identify a user in Spain within the 
local area of Madrid. 

[0003] Identifiers used in modern telecommunication 
25 systems providing, for example, multimedia services (such 
as: video conference, data transfer, multimedia messaging, 
etc., as well as traditional voice-only calls) use to align 
with URI (Uniform Resource Identifier) format. Usually, 
these modern systems support also legacy identifiers, such 
30 as E.164 numbers, for interworking purposes with legacy 
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systems, as well as for keeping associated to the same user 
an old (legacy) identifier. URIs are well-known identifiers 
widely used by Internet application and services for 
identifying resources (either: abstract of physical 
5 entities). URIs are further divided* as "locators" (Uniform 
Resource Locators, URLs) or "names" (Uniform Resource 
Names, URNs) . As opposed to URNs, that are intended to 
merely name a resource (even when the resource itself 
ceases or becomes unavailable) , URLs identifies a resource 

10 by its location in a network (i.e.: identifies and locates 
it) . For the sake of a greater simplicity, and given that 
the abstract conceptual differences between URIs and URLs 
are tiny enough for considering them equivalent when 
referring string of characters that "identify" resources, 

15 the term URL shall be used hereinafter. 

Nowadays, URLs are assigned as identifiers to a plurality 
of heterogeneous resources for which service requests can 
be received. For example, an URL can be used to identify a 
web page, an electronic mail account, a file downloadable 

20 file, etc.. Identifiers associated to users that are served 
for a given service in a specific network domain, use to be 
URLs that has a format that comprises: a user-name portion 
and a domain-portion, separated by the separator character 
" (?" . The domain-portion identifies the network domain 

25 serving a given user, who is named (and identified) as 
specified in the content of the user-name portion in said 
domain. 

[0004] Telecommunication systems using a multimedia 
protocols, such as H.323 protocol (ITU-T recommendation 

30 H.323, November 2000) or SIP protocol (IETF RFC2543 
"Session Initiation Protocol", March 1999), use URLs to 
identify their users (among other type of identifiers) . So, 
a user having a subscription with a telecommunications 
operator that owns a telecommunication system supporting a 

35 multimedia protocol such as SIP, uses to be assigned to an 
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identifier having an URL format (known as SIP-URL) that 
identifies said user in the network domain of said 
operator; for example " sip: John . Doe@Opera torA.se " . 
Similarly, for other communication services, such as 
5 traditional telephony, fax, electronic mail, modem based 
data calls, etc., a plurality of URLs can be defined to 
reach the destination user in the corresponding service 
point according to the requested service (e.g.: a plain 
telephone, the inbox of a mail account, a fax machine, or a 
10 modem); for example: " tel : +98-7-6543210" , 

"mailto :John.Doe@OperatorA.se n , "fax: + 98-7-6543210" , 
"modem:* 98-7-6543210 ; type=v!10 xl . 

[0005] A given user having a subscription with a 
telecommunications operator can, depending on the 

15 capabilities of the telecommunication system of said 
operator, an also depending on his/her subscription 
characteristics, receive a plurality of telecommunication 
services, or just only one type of services, having 
subscribed other services with another operator. 

20 For example, a user can have a subscription with Operator-A 
for basic telephony service, multimedia communication 
service and electronic mail service. Also, a user can have, 
for example, basic telephony and multimedia services 
subscribed with Operator-A, while keeping a subscription 

25 with Operator-B for solely multimedia service. 

An example of a telecommunication system able to provide a 
variety of telecommunication services and handle various 
kind of identifiers for users (including E.164 identifiers 
and URLs) is a 3G (third generation) mobile system having 

30 the, so called, IMS . (Internet Protocol Multimedia 
Subsystem) for providing multimedia services. 



[0006] E.164 identifiers have been widely used for 
identifying users of telecommunication systems providing 
telephony services; and, as mentioned above, many systems 
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still use E.164 identifiers as the only type of identifier 
that a user (originating user) can use for requesting a 
communication service towards another user (destination 
user) . The appearance of new telecommunication services 
5 made traditional telephony operators to offer some of these 
new services to their users. Among reasons such as: to 
allow an smooth migration towards a new telecommunication 
service replacing an equivalent old one (e.g.: a multimedia 
service in replacement of a traditional voice-only 

10 telephony service), and to avoid user 1 s inconvenience of 
publishing his/her new identifier (s) for the new service (s) 
subscribed; a given user subscribes a new service with 
his/her operator, uses to keep his/her old E.164 identifier 
associated also to this new subscription. So, for example, 

15 a given operator owning a 2G system and a 3G system with 
IMS, allows users subscribed to its 2G system to migrate 
their subscription to its 3G system while keeping their old 
E.164 identifiers. This allow these users to receive 
services from other legacy telecommunication systems, such 

20 as for example, calls or SMS (Short Messages) that are 
originally addressed using E.164 identifiers. 

[0007] When routing a service request to its destination 
user that contains an E.164 as identifier for said user, 
for some telecommunication systems (or for some parts of 

25 said system through which a certain protocol is used for 
signaling the service) said E.164 identifier can be found 
as not suitable for routing and/ or identification purposes. 
Also, in a given point of the execution of a service 
request, it can be desirable to select a service point 

30 (e.g. : a given terminal of the destination user) where to 
finally deliver the service, being said user identified in 
said terminal with an identifier which is not the same as 
the one received in the service request. 
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PRIOR ART SOLUTIONS 

[0008] The aforementioned scenario drove to . devise 
solutions for obtaining the collection of identifiers 
related to a given identifier assigned to a user; and, more 
5 precisely (given the wide use made of E.164 identifiers), 
to obtain the collection of identifiers related to a E.164 
identifier. 

[0009] For example, IETF ' s RFC2916 {"E.164 number and 
DNS 11 , September 2000) (wherein the term DNS stands for 

10 "Domain Name System") discloses a DNS-based service to 
obtain information related to the various identifiers and 
service types related to a given E.164 identifier. The 
service provides the plurality of URLs related to a given 
E.164 identifier, and can be used, for example, when a 

15 service request comprising an E.164 identifier is received 
(e.g.: a telephony call, a SMS, a multimedia session, 
etc . ) . . 

[00010] Hereinafter, the term "ENUM-DNS" will be used 
across the present invention to refer to the translation 

20 method and translation system (query translation 
mechanisms, DNS database structure, specific data 
structures for supporting translation of E.164 identifiers 
to URLs, etc.) disclosed in RFC2916 and summarized below 
(the same term is also utilized in another standard 

25 specification that will be further cited across the 
detailed description) . 

[00011] According to RFC2916, a plurality of identifiers 
are stored in. a data base. Said data base is structured and 
accessed (queried) using the well-known DNS technology. 
30 For this purpose the received E.164 identifier is arranged 
(as described below) to query a DNS-based data base in a 
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similar manner as other DNS-based queries are done. Since 
the domain n el64.arpa" is being populated to provide the 
infrastructure in DNS systems for storage of E.164 numbers, 
said domain identifier is included in the query. 
5 For example, for a received E.164 identifier such as: 
9876543210 

the next query is should be made to a DNS: 
0 .1.2.3 .4.5 .6.7 .8.9 .e!64.arpa 

wherein the received digits in the E.164 identifier have 
10 been inverted to fulfil existing DNS structured analysis 

(structured hierarchically from right to left) . 

As a result a plurality of URLs that are stored in the DNS 

in relationship with said E.164 identifier are received as 

a result of said query. Each of these URLs can be related 
15 to a specific service, although more than one can be 

related to the same service. For example, the query can 

yield a set of identifiers such as: 

sip: John . Doe&Opera torA.se (a SIP-URL) 

tel: +98-7-6543210 (a TEL -URL) 

20 fax:+98-7-6543210 (a FAX-URL) 

mail to: John.Doe@OperatorA.se (a MAILTO-URL) 

s±p:JohnnyDoeQOperatorB.fr (a SIP-URL) 

that are stored in DNS as NAPTR RRs (Naming Authority 

Pointer DNS Resource Records) , and that can be used as 

25 valid routable identifiers for further routing the service 

request that contained the E.164 identifier. 

[00012] Among said identifiers, the querying entity (for 
example, a node in the telecommunication service) can 
select one of them and further route the service request 

30 according to it. For example, the most appropriate URL for 
delivering the requested service can be selected according 
to the requested capabilities; so for example, if the 
service requested is a voice call, then any SIP-URL can be 
selected for delivering it into a SIP-enabled terminal of 

35 the referenced destination user. Alternatively, the second 
URL (tel ; +98-7-6543210) could be selected if it is desired 
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to deliver the call, for example, to a plain telephone set 
through a legacy telephony system. 

The further routing of the service, would depend on the 
nature of the selected URL. So, for example, if the 
5 selected URL has a user-name portion and a domain-name 
portion, then the service is routed primarily to the domain 
specified by the domain-name portion. For example, if the 
selected URL is the first one, then the service is routed 
towards the network domain of "OperatorA" in Sweden. If, 
10 however, the fifth URL is selected, then the service should 
be routed towards the network domain of "OperatorB" in 
France . 

[00013] However, the above referenced RFC2916 does not 
discloses what to do when more than one identifier is 
15 received related to the same service type for a ENUM-DNS 
query translation mechanism (for example, when more than 
one SIP-URL are received as a response to a query made with 
an E.164 identifier), and even having the same "order" and 
"preference" fields. 

20 [00014] Avoiding this non desirable situations by means of 
defining a single URL per service related to an E.164 
identifier could be not feasible. In fact, the identifiers 
to be stored within NAPTR RRs in DNS related to E.164 
identifiers can be (as for other similar issues dealing 

25 with identifiers of telecommunication users, such as Number 
Portability) a national regulatory matter that can differ 
from country to country. So, for example, in some 
situations the content of said resource records will depend 
to a great extent on what the user assigned to the E.164 

30 identifier decides; while in other situations, the final 
content shall be determined by the operator that 
(originally) owns the subscription said E.164 identifier 
belongs to (i.e.: the "home operator" for said identifier). 
Then, this would drive to situations in which there can be 
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more than one URL per service related to a given E.164 
identifier stored in ENUM-DNS . 

On the other hand, while keeping the global addressing 
possibilities of the E.164 identifier largely used by 
5 (assigned to) a given user, it should not be desirable to 
limit the number of subscriptions said user can have to a 
given (new) service (such as a multimedia service based on 
SIP) with more than one telecommunications operator. 

SUMMARY OF THE INVENTION 

10 [00015] The present invention provides a method, an 
apparatus and a system for routing a service request in a 
telecommunication system when a plurality of routable 
identifiers, -related to an identifier received in the 
service request, are obtained for routing said service. 

15 [00016] According one aspect of the present invention, it 
is provided a method for routing a service request that 
contains a specific identifier associated to the user who 
is the destination of said service. The method comprises a 
first step in which a plurality of identifiers are stored 

20 in relationship with said specific identifier; any of said 
plurality of identifiers being suitable for routing further 
service requests that can be received for said destination 
user and that comprise said specific identifier, wherein, 
at least one identifier of said plurality of identifiers 

25 has a format that comprises a user-name portion and a 
domain-name portion, being said specific identifier 
contained within the user-name portion. In a further step, 
when a service request comprising said specific identifier 
is received, all or a part of said plurality of identifiers 

30 related to the received specific identifier are obtained; 
then, if one identifier among said plurality of identifiers 
has a format as described above, and its user-name portion 
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contains the received specific identifier, it is selected 
for further routing the service. 

[00017] According to a further aspect of the invention, it 
is provided an apparatus for routing a service request in a 
5 telecommunication system. The apparatus comprises: 
communication means, arranged for receiving a service 
request that contains a specific identifier assigned to the 
user who is the destination of said service; processing 
means, arranged for obtaining the plurality of identifiers 

10 related to the received specific identifier that are 
suitable for routing a service requests that contains said 
specific identifier, and are further arranged for selecting 
an identifier among said plurality of identifiers that has 
a format that comprises a user-name portion and a domain- 

15 name portion, wherein the user-name portion contains the 
identifier received in the service request; and routing 
means arranged to further route the received service 
request according to the selected identifier. 

[00018] According to a further aspect of the invention, it 
20 is provided a system for routing a service request in a 
telecommunication system. The system comprises: a data base 
and a serving node in said telecommunications network which 
is in charge of receiving a service request towards a 
destination user, and further routing said service request. 
25 The data base stores a plurality of identifiers that are 
related to a specific identifier associated to a user, and 
it is arranged for answering a query that comprises the 
content of said specific identifier with all or part of 
said plurality of identifiers. The serving node is arranged 
30 to send a query to said data base when it receives a 
service request that contains said specific identifier, 
said query comprising the content of the identifier 
received in the service request. When the response, to the 
query is received in the serving node, it is arranged to 
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select one identifier, among the plurality of identifiers 
received in the query, that has a format comprising a user- 
name portion and a domain-name portion if the user-name 
portion contains the identifier received in the service 
5 request. 

[00019] In situations in which two or more identifiers are 
obtained for routing a service request, and specially when 
these identifiers are related to different service types 
and/or different network domains; the aspects disclosed in 

10 this invention allows to identify a particular network 
domain that holds an identifier that contains the one 
received in the service request, and to route the service 
to it. This permits further decisions for delivering said 
service, such as, for example, change of service type, 

15 selection of the destination terminal, etc., to be taken in 
the identified network domain. 

BRIEF DESCRIPTION OF DRAWINGS 

[0010] Fig.l shows an schematic view of a two serving 
nodes of a telecommunication system and a signaling flow of 
20 a service request and its further routing according to the 
invention: 

DETAILED DESCRIPTION 

[00020] The invention shall now be described in detail 
with reference to Fig.l according to a preferred 

25 embodiment. Said preferred embodiment considers a 3G mobile 
system that implements the so called IMS (Internet Protocol 
Multimedia Subsystem) and its standardized protocol for 
signaling services, as an example of a telecommunication 
system where the objects, features and advantages of this 

30 invention can apply. 
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3G systems are standardized by the standardization forum 
3GPP (3 rd . Generation Partnership Project); being the well 
known protocol SIP (Session Initiation Protocol) the one 
chosen by 3GPP for signaling services within the IMS of a 
5 3G system. 

As mentioned previously, this kind of telecommunication 
systems (3G systems having the subsystem IMS) are able to 
provide variety of telecommunication services, such as 
voice calls through circuit-switched technology, voice or 

10 multimedia sessions through packet-switched technology, 
etc.; and handle various kind of identifiers for 
identifying users, including E.164 and URLs. So, when 
handling service requests, they can face the need of having 
to translate a given identifier, such as an E.164 telephone 

15 number, to a more suitable identifier, such as a SIP-URL, 
for further routing the service to its final destination. 

[00021] However, it shall be understood that the scope of 
the present invention is not limited to said 3G systems nor 
to a specific signaling protocol; and that a skilled person 

20 can readily apply it to any telecommunication system that 
receives a service request that contains a given identifier 
associated to the destination of said service, when said 
identifier is, either: not suitable, or not wanted for 
further routing the service, and , at least, one of a 

25 plurality of routable identifiers related to said given 
identifier has to be used for said purpose. 

[00022] For the IMS subsystem of a 3G mobile system, the 
3GPP forum has defined a set of functional server entities 
in charge of various specialized functions. Among them 
30 there are the, so called, CSCFs (Call State Control 
Functions) which are in- charge of serving control for 
services. A CSCF is a functional entity that performs a set 
of functions, such as: communication functions, to 
communicate with other entities; processing functions, for 
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carrying out various service logic related to a service 
which is handled on it; and routing functions, for routing 
communications to other entities. 

Depending on implementation aspects (not standardized by 
5 3GPP, nor relevant for the understanding and scope of the 
present invention) , a CSCF can be located within a physical 
machine (i.e.: a physical telecommunication node), or 
distributed across a plurality of physical machines that 
co-operate for performing its functions. 
10 As a summary, it can be assumed that a CSCF is a serving 
node in a telecommunication system, such as an exchange in 
a PSTN, or a MSC (Mobile Switching Centre) in a 2G mobile 
system, in charge of performing control functions for the 
services it serves (i.e.: receives, routes or processes) . 

15 [00023] According to 3GPP terminology for IMS entities, a 
CSCF is further named as P-CSCF (Proxy-CSCF) , I-CSCF 
(Interrogating-CSCF) or S-CSCF (Serving-CSCF) according to 
its role while handling a service request. So, a CSCF is 
named P-CSCF when communicating with an end user terminal, 

20 a I-CSCF when it is the first serving node within an 
operator ! s network that receives services requests . for a 
destination user who is subscriber of said operator, and S- 
CSCF when it is in charge of serving control for a service 
either: originated by a user, or terminating in a user, to 

25 whom it has been assigned to serve. 

[00024] Reference is now made to Fig.l to illustrate the 
features of the present invention in a state-of-the-art 3G 
telecommunication system having IMS, and arranged to query 
an ENUM-DNS data base to obtain identifiers related to a 
30 given E.164 identifier. 

In Fig.l two CSCFs are shown (S-CSCF, I-CSCF), each one 
having its own name (cscf.OperatorX.fr, esc f .Operator A. se) , 
that intends to represent a CSCF in the network domain of a 
given operator ( "OperatorX" ) in a given country (France) 
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that acts as Serving-CSCF for the user (or entity) 
originating said service, and another one belonging to 
another operator ( "Opera tor A" ) in another country (Sweden) 
that acts as Interrogating-CSCF for the destination of the 
5 service. However, both CSCFs depicted in Fig.l could belong 
to the same operator, being the case of distinct operators 
more appropriate to highlight the advantages of the 
invention. 

At this point, it shall be noticed that, according to 3GPP 

10 specifications for IMS, the CSCFs are referenced with their 
individual names; as it is shown, for example, in 3 GPP 
specification 24.228 (version V5.0.0, March 2002) that 
shows detailed signaling flows for services in IMS. Since 
said individual names (URLs) have to be resolved into the 

15 corresponding individual addresses suitable for addressing 
messages according to the underlying network protocol 
(e.g.: an Internet Protocol address, or IP-address), by 
using, for instance DNS or similar technique) , they usually 
shall contain a domain portion identifying the network 

20 realm of the 3G system operator they belong to. 

Fig.l also shows an ENUM-DSN data base. It can comprise one 
data base, or a set of hierarchically related data bases. 
In any case, particular implementation details related to 
said database, even if it is based on DNS technology or 

25 not, are not relevant for the scope of the present 
invention; wherein, the only relevant aspects for its 
understanding are: that said data base is in charge of 
storing a collection of identifiers related to a given 
identifier; and that said data base is arranged for 

30 receiving a query that contains said given identifier, and 
to answer the query with one or more among said plurality 
of identifiers. 

[00025] Step 1 in Fig.l represents the reception of a 
service request in a CSCF (S-CSCF) . The service can be, for 
35 example, a session (i.e.: call, multimedia session) 
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requested towards a destination user that can be located 
within the network domain of the operator where said CSCF 
belongs to, or located within the network domain of another 
operator. 

5 As cited above, services within the IMS of a 3G system are 
signalled by using SIP protocol. So, in this example case, 
a SIP message INVITE should be received by the 
communication means of said CSCF. 

The INVITE received in step 1 shall contain a valid 
10 identifier for the user who is destination of the service. 
According to SIP protocol, said identifier takes the form 
of a URL. So, from SIP protocol point of view, there would 
not be any problem for routing the received service request 
(INVITE) according to the URL indicated as destination. 
15 Said URL could be, for example, a TEL-URL (URL for 
telephony, as disclosed in RFC2806 "URLs for Telephone 
Calls", April 2000) or a SIP-URL (URL for SIP, as disclosed 
in the aforementioned RFC2543 "Session Initiation 
Protocol") . This would then not preclude to further route 
20 the received INVITE according to the received URL 
associated to the destination, and without modifying said 
URL. 

In some situations, it might be wanted, however, to change 
the destination of the INVITE. For example, the destination 

25 user has registered into a SIP-based system from two 
terminals and has specified a certain delivery criteria for 
receiving services. In this case, for example, an 
specialized SIP-server can provide the appropriate 
identifiers in order to further route the INVITE to any (or 

30 both) of these two terminals. 

[00026] However, as specified for example in 3GPP 
specification 23.228 (version V5.3.0, January 2002) (as 
well as in older versions of the same specification) , non 
SIP-URLs (such as a TEL-URLs) shall not be used for routing 
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services within the IMS of a 3G system, and would have to 
be converted into routable SIP-URLs using ENUM-DNS. 
So, for example, if the URL for the destination received in 
the INVITE of step 3 is a TEL-URL such as: 
5 tel: +98-7-6543210 

it would have to be translated, by using ENUM-DNS or any 
other suitable mechanism into a routable SIP-URL. 
For this purpose, a state-of-the-art serving node of a 
telecommunication system, such as the CSCF (S-CSCF) of the 
10 example case, would query in step 2 to an ENUM-DNS data 
base. The query would (as mentioned earlier in connection 
with the prior-art) comprise the received E.164 identifier 
arranged properly to query to a DNS-based data base. 
According to this, the query sent in step 3 would contain: 

15 0.1:2.3.4.5.6.7 .8.9. el64.arpa 

[00027] The queried data base can have a plurality of 
identifiers related to the identifier "9876543210"; 
however, for the purpose of ENUM-DNS lookup, the only 
relevant to this kind of query (E.164 to URL) are the 
20 identifiers having URL format. Therefore, the ENUM-DSN data 
base would answer back with those URLs that are related in 
said data base to the E.164 identifier used in the query. 
Using the example case depicted in Fig.l, in step 3 the 
CSCF (S-CSCF) would receive the next URLs: 

25 sip: JohnnyDoe&Oper at orB. fr 

mailto:John.Doe0OperatorA.se 
sip: 987654321O0OperatorA.se 
tel: +98-7-6543210 

[00028] In this example case, since multiple URLs are 
30 received, processing means in the CSCF (S-CSCF), unless 
forking method for multiple service delivery are 
implemented (which is costly and, sometimes, not 
effective) , would have to select in step 4 one these URLs 
and route the service according to it. If the TEL-URL 



WO 2004/006534 PCT/SE2003/000999 

16 

{tel: +98-7-6543210) is selected, a telephony call should 
then be established by towards the E.164 identifier 
contained in said TEL-URL. If said E.164 identifier does 
not belongs to OperatorX's domain, then it can be, for 
5 example, routed to the PSTN through the signaling and media 
gateways that link the telecommunication system of 
OperatorX with a PSTN operator that would end up in the 
network domain of the operator that handles a telephony 
subscription addressed by said .164 identifier. 

10 Also, there could be the particular case in which all the 
received identifiers would belong to the same operator as 
the CSCF that received the INVITE (OperatorX) . In this 
case, the CSCF (S-CSCF) can query with any of the 
identifiers to the home server entity (known as HSS or HLR) 

15 of said OperatorX that would, in turn, provide the address 
of the CSCF serving the corresponding user addressed by 
said identifiers. The service would be further routed with 
any of the received SIP-URLs to said CSCF that, in turn, 
could apply a further routing criteria according to, for 

20 instance, user preferences or user profile. So, in this 
latest case, it would be the CSCF serving to said user the 
one deciding where to route the service. 

[00029] However, if the identifiers received in step 3 
does not belong to the operator said CSCF (S-CSCF) belongs 

25 to (OperatorX) , user preference data and/or user profile 
data of a destination user that belong to another operator 
(e.g.: OperatorA or OperatorB) , and that would allow this 
CSCF (S-CSCF) to make a selection with a certain basis, are 
far away to be known (or accessed) by this CSCF of 

30 OperatorX. In fact, even the identifiers received in step 3 
would belong to the same operator said CSCF (S-CSCF) 
belongs to, IMS standardized procedures preclude in this 
situation to a CSCF acting as a originating S-CSCF to query 
to the HSS for this purpose; and also, as mentioned before, 
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IMS standardized procedures preclude the further routing of 

the service with other identifier than a SIP-URL . 

[00030] Moreover, even in case that one or more SIP-URLs 
are received from the data base that pertains to the domain 
5 of OperatorX, if there is at least one SIP-URL among the 
ones received from the data base that pertains to another 
operator, it can be doubtful to take the decision of 
discarding that SIP-URL for further routing the service. 
For instance, two URL are received as a response to the 

10 query sent to the data base; one URL belongs to OperatorX, 
while the other to OperatorA. If the destination 
subscriber, to whom the E.164 is assigned, had originally, 
and still has, a basic (legacy) telephony subscription with 
OperatorA associated to said E.164 identifier (e.g: the 

15 number series of said E.164 identifier originally belonged 
to OperatorA) ; and has now also a multimedia subscription 
with said OperatorA; then to route the service towards 
OperatorA can probably be the most appropriate decision; 
mainly if the E.164 identifier can be subject to Number 

20 Portability and queries for portability are made in the 
Number Range Holder Network. So, once the service would get 
OperatorA 1 s domain, user preferences and user profile 
related to the subscription of the destination user in said 
domain shall be further checked to determine the final 

25 routing and delivery criteria for the service. However, 
these (possible) facts can also be far away to be known (or 
accessed) by this CSCF (S-CSCF) . 

[00031] To overcome the problems above, as a part of the 
administrative process of populate data through DNS system 
30 (such as done for populating data related to Number 
Portability) , an operator that has, for example, a 
situation similar as the one described above for OperatorA, 
in which, it holds a basic (legacy) telephony subscription 
addressed with a legacy identifier (such as an E.164 
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identifier) not suitable or not desirable for routing 
according to a new service type, and a new subscription for 
a new service type (such as. multimedia services via SIP) , 
or the same subscription encompassing both services; should 
5 populate a URL to be stored in DNS-ENUM that allows 
identify uniquely said, operator's domain as the one 
primarily holding said legacy identifier (e.g.: an E.164 
identifier) . 

[00032] In cases where the new service type uses URL 
10 identifiers, this can be accomplished by defining an URL 
having, in the user-name portion the content of the legacy 
identifier, while in the domain-name portion contains the 
appropriate domain identifier, so as to form a routable 
FQDN (Full Qualified Domain Name) . Said URL, once stored, 
15 for example, in ENUM-DNS, together with the rest of 
identifiers related to. the legacy identifier, would allow 
to distinguish it from the others and further route the 
service according to it. 

In the particular case of E.164 to URL translation; and, 
20 more precisely in case of E.164 to SIP-URL translation, the 
format of the URL to be. populated shall contain the E.164 
identifier in a distinguishable format. For example, for an 
E.164 such as 9876543210 which is "owned" by operator 
Operator A in Sweden, the SIP-URL could have a format such 
25 as: 

sip : 987654321 O&Opera tor A . se . 

Optionally, the user-name portion could contain additional 
information for various purposes, such as reinforcing the 
use of this URL, indicate identifier subject to Number 
30 Portability, etc. For the same case used as example, a 
readily distinguishable formats could also be: 

sip : 9 87 654321 0.E164 QOpera tor A .se, 

sip :non__ported_indi cation. 98 7654321 O&OperatorA . se , 
sip:ported_indication. 9876543210.ported_identifier@OperatorC. it. 
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[00033] According to the invention, processing means in 
the CSCF (S-CSCF) selects in step 4 a distinguishable URL as 
described above that contains the E.164 identifier used in 
the query of step 2 , and further route the service 
5 according to said URL. This process, can imply a further 
query (not shown in Fig.l) to a translation service (such 
as DNS) to obtain name and/or network address of the 
corresponding CSCF where to send the INVITE in step 5 . 
Additionally, if an indication of "non_ported" identifier 

10 was also received in the selected URL, a further query that 
could have been requested otherwise by this CSCF (S-CSCF) 
or by other serving node to obtain number portability 
information, can be avoided by considering said indication. 
Similarly, if an indication of ■ ported" identifier was 

15 also received in the selected URL, a further query that 
could have been requested otherwise by this CSCF (S-CSCF) 
or by " other serving node to obtain number portability 
information, can be avoided by considering said indication 
together with the (new) ported identifier received that in 

20 this case, preferably, can contain the domain name of the 
(final) destination network handling the ported identifier. 

[00034] Upon reception in step 5 of the INVITE in the CSCF 
that first receives services requests for a destination 
user (I-CSCF) , I-CSCF of OperatorA in the example depicted 

25 in Fig.l, further state-of-the-art steps can take place. 
This implies, for example, query to the home server entity, 
HSS, of OperatorA that will provide the address of an CSCF, 
acting as S-CSCF, that is in charge of serving to the user 
who has assigned the identifier received in the INVITE 

30 (i.e. : the destination user) . This CSCF can apply a further 
routing criteria which, for said destination user, are 
available to this CSCF in this destination domain of 
OperatorA. Said routing criteria can be based, for example, 
on user preferences, user profile, user location, etc.; and 

35 can involve, for example, a subsequent change of the 
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session to circuit-switched 
happen if, for instance, 
programmed a call forwarding 
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service type (e.g.: from SIP 
telephony call) , as it would 
the destination user has 
towards another destination. 



